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A METHOD AND SYSTEM FOR ACCESS CONTROL 

FIELD OF THE INVENTION 
5 The invennon relates to the field of access control, and more specifically to a metfiod and 
system for conuolling access to healtii care systons to ensure patient privacy. 

BACKGROUND TO THE INVENTION 

Over the years, especially in the past decade, significant efforts have been made to reduce the 
10 costs associated with the provision of health care services while maintaining efficiency and 
quality. As many would agree, the costs of health care systems in many countries, especially 
western, developed countries, has continued to increase at an astonishing rate. One reason for 
the increase in costs has been a tremendous increase in the amount of information that is 
generated during the treatment of a patient This information takes many forms. For example, 
15 providing health care services to an automobile accident victim may result in the creation of a 
huge amount of information. Basic information relating to their name, address and other 
personal information and their health insurance information may be entered into a computer 
system creating an electronic record. Paper forais completed by emergency services personnel at 
the scene of die accident may be created- X-rays and advanced imaging technologies may create 
20 fihn-based, tape-based and digital-based imaging records. The list goes on and on. 

Part of the effons to reduce costs has focused on the deployment of infonnation technology to 
collect, collate and distribute electronic infonnation where needed. Unfortunately, the 
development of these information technologies has been somewhat haphazard resulting in many 
25 different stores of information, many points of data entry and many points of data access. This, 
some have said, has reduced efficioicy and increased costs. Moreover, all of the infonnation 
may not be compatible with each information technology system deployed by one or more 
health care providers. 

30 Running in parallel with the vast increase in the creation of health care information has been an 
increased awareness of the sensitivity and value of this information. Accordingly, efforts are 
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ongoing in the protection of ifais infonnadon. This infonnation or data protection generally falls 
under a few categories of efforts. 

A first category of efforts relating the protection of infonnation generally relates to ensuring that 
information is not lost Accordingly, electronic data is regularly backed up by most modem 
infonnation technology systems. 



A second categoiy of infonnation protection relates to ensuring that the data is private. That is, 
only those needing access should be granted access. Moreover, access to a selected patient's 

10 information granted to a particular person should not be all encompassing. Rather, each person 
needing access should only be granted access to those specific pieces of information to that 
selected patient needed for the particular person to perform their task or job. For example, a 
physician mi^t be granted access to all health-related information for each person that the 
physician is treating but not all of the infonnation relating to each of those patients. For 

15 instance, the physician may be prevented fiom accessing data for his/her patients relating to 
their health insurance or other accounting infomaiation. In contrast to the physician, certain 
accounting pereonnel may need to have access to some infonnation for all patients, hi this 
instance, the accounting personnel may be required to have access to each patient's accounting 
infonnation but not any infoimation relating to a patient's diagnostic and test results, for 

20 example. 



A third category of information protection relates generally to security. That is, measures are 
needed to be in place to enstire that unauthorised access to infonnation does not occur. 
Historically, these security efforts have bera fairly limited. For example, a health care centre 
25 would provide each employee and contractor wifli a user name and password that would be 
required to access any electronic system. 

Unfortunately, tiie efforts to date in providing mformation protection have been less than 
adequate. Moreover, the US federal govenmient, like many other similar efforts by otiier 
30 governments around the worid, has enacted the Health Insurance Portability and Accountability 
Act (HEPAA) in an effort to, inter alia, force health care providers and those handling patient 
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infoimation (e.g., hsdixh care centre employees, coniractors, insurance companies, etc.) to 
satisfy at least minimum levels of health care related information protection. The HIPAA 
requires certain levels of security and privacy for all protected healih infoimation (PHI). 



5 Unfortunately, resulting irom the many varied forms of PHI (electronic and otherwise), the 
varied types of electronic devices Hm are used to create, store and access PHI (e.g., MRI 
scanners, CT scanners, automated test equipment, image retrieval computers, general purpose 
computers, etc.) and other fiictors, the ability to provide the desired (and now, due to ihe 
HIPAA, requisite) level of PHI security and privacy is typically inadequate. 

10 

Accordingly, some maimer is required to address, at least in part, some of the shortcomings 
described above. The Integrated Health Initiative (IHE), a joint initiative between Radiological 
Society of North America (RSNA) and Health Level 7 (HL7) organisations has provided the 
Basic Security Integration Profile tiiat establishes security measures, which provide patient 
1 5 information confidentiality, data integrity and user accountability (see www4rsna.0rg/ihe) 



SUMMARY OF THE INVENTION 

Advantageously, aspects of the invention address some of the shortcomings described above. In 
20 one aspect of the inv^tion, embodim^ts of the invention can be superimposed upon the 
existing network system, which includes a number of nodes interconnected by the underiying 
conununicarions network. In one embodiment, an access control node is interposed between 
each node and the remainder of the networic. The access control node is adapted to transmit 
information about the node and the user anempiing to access the node to a server used for 
25 maintaining security and audit information. This information may take the form of node 
identification data (thus identifying the node) and user identification and password data (Aus 
ensuring that the user is associated with an active account and the user has entered the correa 
password ensuring that the user has been authenticated). If the node is not recognised by the 
server, then no access to protected information (e.g., PHI) is allowed. If; however, the node is 
30 recognised, then access to PHI requires that the user also be authenticated. Assuming both 
conditions exist, aspects of the invention will determine (based on a rq>ository of information 
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about users) the data each user is entitled to access and the functionality of the node that is to be 
made available to the user. 

Aspects of the invention may place limitations on the functionality offered by the node to which 
die user should be granted access. That is, although a user may be anempting to access data 
S from a node which has a set of functions (e.g., printing, storing data to a removable media, 
displaying video signals, etc.^ aspects of the invention enable only a subset of these functions to 
be made available depending on the rights which have been granted to a user. 

In other aspects of the invention, messages that are being nransmined to or from the node to 
which a user has access will be monitt>red. These messages may be intercepted to detemiine 
whether the user, based on his/her access rights, should be receiving the messages which are 
being transmitted to the node or, alternatively, whetfier the data being traasmitted by the user 
should reach its intended destination, also based on the user's access ri^ts. Additionally or 
alternatively, aspects of the invention will capture from these intercepted messages information 
about the activities that involve the user. From this capmred information, a detailed audit log 
can be coated for future reference* 

In another aspect of the invention there is provided a device that operates to selectively control a 
node associated with the device. This selective control may include providing electrical power 
to only portions of the associated node or enabling video (or other data stream) signals (analog 
or digital) to be passed to the associated node. The selective control may resuh from the co- 
20 operation between die device and a server that operates to determine a user's permissions to data 
and functionality. 

In one aspect of the invention there is provided a method for providing access to data stored in a 
repository forming pan of a netwoiic, said access being requested from a node also forming part 
of said network, said method comprising: receiving at an access control node user identification, 
25 user password and node identification data, said access control node inteiposed between said 
node and said repository, said access control node transmitting over said network said user 
identification and node identification requesting authentication for said access request; said 
access control node receiving control signals responsive to said authentication request; and 
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responsive to said received control signals, selectively providing access to a subset of the 
functionality provided by said node. 

In one aspect of the invention there is provided a method for providing access to data stored in a 
repository fonning part of a netwoiic, said access being requested from a node forming part of 
S said network, said method comprising: receiving user identification and node identification data 
firom an access control node assodated with said node; and transmitting control signals to said 
access control node, said control signals indicating limitations on the type of fimctionality to be 
provided to the user by said node, said user associated with said user identification. 

In one aspect of the invention there is provided a device for providing control of a node, said 
10 node fomiing part of a network, said device comprising: an input for receiving user 
identification, user password and node identification data, said device interposed between said 
node and the remainder of said network; an output adapted to transmit over said network said 
user identification and node identification and data requesting authentication of the user 
identification and node identification and, responsive thereto, receive control signals responsive 
15 to said authentication request; and a switching device for selectively providing access to a 
subset of the fimctionality provided by said node. 

hi one aspect of the invention there is provided a computer readable media storing data and 
instructions, said data and instructions when executed by a general purpose computer adapt said 
computer to provide access to data stored in a repository fomiing part of a network, said access 

20 being requested from a node fonning part of said network, said data and instructions adapting 
said general purpose computer to: receive data requesting authentication of the user 
identification and node identification data from an access control node associated with said 
node; and transmit control signals to said access control node, said control signals indicating 
limitations on the type of fimctionality to be provided to the user by said node, said user 

25 associated with said user identification. 

In one aspect of the invention there is provided a method for generating audit logs for a 
networic, said network comprising a plurality of nodes interconnected by way of a 
communications networic, said method comprising: upon initial access by any user of a plurality 
of users, generating a login event record from user identification data received from an access 
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control point from a plurality access control points, each of said plurality of access control 
points associated with one of said plurality of nodes; intercepting all messages transrained to or 
from each of said plurality of nodes; and storing an audit log event in a repository for each 
activity identified in said intercepted messages. 

5 In one aspect of the invention there is provided a method for providing access to data for a 
plurality of users, said to data stored on a network, said network comprising a plurality of nodes, 
each of said plurality nodes associated with an access control node, each of said access control 
nodes interposed between its associated node and the network, said method comprising: 
defining a plurality of roles to which users will associated; for each role defined, identifying the 
10 data for which access is to be granted and the type of fimctionality at each of said plurality of 
nodes that is to be made available to a user associated with a role; and associating each of said 
plurality of users with at least one of said defined roles. 



BRIEF DESCRIPTION OF THE DRAWINGS 

15 

Embodiments of the invention may best be xmderstood by referring to the following description 
and accompanying drawings. In the description and drawings, like numerals refer to like 
structures and/or processes. In the drawings: 

20 FIG. 1 is a block diagram illustrating audit response modules in accordance with an embodiment 
of the invention; 

FIG. 2 is a block diagram illustrating the components forming the universal compliance module, 
a client side application, in accordance with an embodiment of the invention; 
FIG. 3 is a block diagram illustrating directory caching in accordance with an embodiment of 
25 the invention; 

FIG. 4 is a block diagram illustrating an exemplary access control node for implementing an 
embodiment of the invention; 

FIG. 5 is a printed circuit board layout diagram illustrating a VGA switch in accordance with an 
embodiment of the invention; 
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FIG. 6, which comprises FIGS, 6(a), 6(b) and 6(c), is an exemplary bill of materials for the 
VGA switch of FIG. 5 in accordance with an embodiment of die invention; 
FIG, 7, which comprises FIGS, 7(a), 7(b), 7(c) and 7(d), is a schematic diagram for the VGA 
switch of FIG, 5 in accordance with an embodiment of the invention; 
S FIGS. 8, 9(a)-9(d), and 1 3 are wiring diagrams illustrating an alternate switch in accordance 
with an embodiment of the invention; 

FIG. 10 is a line diagram illustrating card reader timing in accordance vn&t an embodiment of 
the invention; 

FIG. 1 1 is a flow cban illustrating directory caching logic in accordance widi an embodiment of 
10 the invention; and, 

FIG. 12 is an exemplary listing of a XML log event in accordance with an embodiment of the 
invention. 



DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 



15 



In the following description, numaous specific details are set forth to provide a thorough 
understanding of the invention However, it is understood that the invention may be practised 
without these specific details. In other instances, well-known structures and/or processes have 
not been described or shown in detail in order not to obscure the invention. In the description 
20 and drawings, like numerals refer to like structures and/or processes. 

An embodiment of tiie present invention will be described under the following headings: 

1. Introduction 

25 2. Definitions 

3. Product Description 
3.1 Product Concept 

4. Modules 

4.1 Security Repository (SR) 
30 4. 1 • 1 Archive Module 

4.1 .2 Reporting Module 

4. 1 .3 Status & Alamfi Module 

4.2 Universal Compliance Module (UCM) 
4-2. 1 Universal Compliance Module Application 

35 4.2.2 User Authenticator Module 

4.2,3 Card Authenticator Module 
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4.2.4 Logging API Module 

4.2.5 Network Gateway Module 

4^2 .6 User Directory Caching Module 
4.2.7 Switcher Control Module 
5 4.3 Support Modules 

4.3.1 User Directory 

5- HIPAA Compliance 

6. Detailed Design Description 

6. 1 Security Repository (SR) 
10 6.1.1 Archive Module 

6. 1 .2 Reporting Module 

6. 1 .3 Status & Alarm Module 

6.2 Universal Compliance Module (UCM) 
6,2. 1 User Autiienticator Module 

15 6.2.2 Card Reader Module 

6.2.3 Logging API Module 

6.2.4 Network Gateway Module 

6.2.5 Directory Caching Module 

6.2.6 Switcher Control Module 
20 6.2.7 Fail-Safe Operation 

6.3 Support Modules 

6.3.1 User Directory 

6.3 .2 Information Required from the Directory 

7. Summary 

25 

1. Introduction 

The invention or embodiments thereof may be used lo satisfy some of the requirements of the 
Health Insurance Portability & Accountability Act of 1996. Althougji preferred embodiments of 
the invention are described herein, it will be understood by those skilled in the an that variations 
30 may be made thereto without departing from the spirit of the invention. Further, even though the 
invention is described to addressing requirements related to the HIPAA, it will be understood by 
those skilled in the art that the invention is applicable to oflier information management systems. 

The preferred embodiment described herein provides, amongst many oAer advantages, 
35 information security and privacy of information accessible thiou^ a computer system. 
Moreover, detailed audit logs detailing any access and/or attempted access to the information 
(e.g., PHI) are created and/or accessed in order to comply with the required security and privacy 
controls of HIPAA. 
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In overview of the exemplary embodiment of the invention, a collection of devices which can 
either display, create, delete or odierwise access PHI (hereinafter these devices are referred lo 
herein as '*nodes*') form a domain. This domain may include any type of node regardless of its 
geographical locality. For example, while most nodes may be physically present in a health care 
S centre (e.g., a hospital campus, a health care business park, etc.), many of the nodes may be 
physically present at remote locations. These remote locations may be, for example, the office 
of physician that remotely connects to the health care centre's data repositories, a laboratory 
providing specialised diagnostic testing for patients of the healdi care centre, an office of an 
insurance provider, an office of a govermnrat regulatory agency requiring audit information or 

10 the like. As will be appreciated by those of ordinaxy skill in the art, the types of remote locations 
are quite numerable. It must be recalled that the method of connecting these various nodes may 
include conventional Uiformation Technology (IT) networks (e.g., local area networks (LANs), 
wide area networks (WANs), metro area networks (MANs) and the like) but may also include 
other forais of communication (e.g., television or satellite communications and the like). 

1 5 Moreover, persons of ordinary skill will understand that die nodes may include not only IT type 
devices (e.g., electronic imaging devices that connect to a LANAVAN, general purpose 
computers, dumb terminals, and the like) but also include many analog devices (e.g., televisions, 
video-cassette recorders, film processing systems, etc.). 

20 To provide for security and privacy of PHI, a^ects of the invention described herein embody 
the requirements of the IHE Basic Security Integration Profile (SEC) in an access control node 
(i.e., a conventional general purpose computer which has been adapted, as described in greater 
detail below, to enable control of PHI available to a user based on the peraiission which has 
been granted to the user). The access control node is installed between any node and the other 

25 portions of the domain. That is, for each node, there is an associated access control node 

Once each node in a domain has been secured throu^ the introduction of embodiments of the 
various aspects of the present invention, the domain can then be said to be secure. 

30 In satisfaction of aspects of the IHE SEC, the access control node 400 (Fia4) provides, inter 
alia, three main functions: (1) authentication of a user or operator trying to access (e.g., review. 
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delete, view, update, create, distribute, etc.) PHI; (2) authentication of the node fiom which the 
anempt to access PHI is being made; and (3) the generation and transmission of audit events 
relating to the node associated with the access control node. Related to these functions, the 
access control node may, in some embodiments, also operate to either provide or deny electrical 
S power to the associated node or portions thereof. Additionally, the access control node (also 
referred to as the HIPAAT gateway), based on the access granted to a user, may eiih» peimit or 
deny the transmission of various I/O data streams (e.g., video, audio, etc.), whether analog or 
digital, to or fcom the node. It is to be noted diat a selected node may include several 
input/output (I/O) devices each of whidi may be authoiticated and access granted or denied 
10 indqjendently of each other by the access control node. The access control node is functionally 
driven, in the exemplary embodiment, by software referred to herein as the Universal 
Compliance Module 

In an example operation, an operator desires to review a particular patient's PHI. In this 
exemplary operation die operator is a radiology tedmician requesting to review a recent MRI 
scan taken of die patient Hie request is being made directly through the MRI scanning device - 
the node 460. In this case, the MRI scanner/node includes several different I/O components, 
each of which provides various types of potential access to PHI. For example, the MRI scanner 
is connected to a general-purpose computer, an external analog monitor, a prints and removable 
media storage device. Prior to the installation of die system described and claimed herein, the 
MRI scanner was direcdy connected to die computer network of die healdi centre in which it is 
housed. In the exemplary embodiment an access control node embodying aspects of the device 
is interposed between the MRI scanner and die healdi centre's network. 

In the exemplary opaanon, die radiology technician may be presented with login screen (i.e., a 
screen to enter a unique usemame and password combination) by die access control node 400 
once the user has been provisionally audienticated. The access contiol node 400 provides 
audientication dirough a user identification token (e.g., a magnetic card and an associated reader 
410). As will be appreciated odier forms of user audientication could be employed. For 
example, some biometrics device such as a fingeiprint scanner, retinal scanner or the like (e.g., 
an RFID radio transmission) could be employed. 
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Initially, the technician swipes his/her magnetic card through the magnetic card reader 410 in 
order for the login screen to be presented and for the requisite login data to be provided (through 
an input device such as, for example, a keyboard or key pad 410). The access control node 400 
5 queries a user directory sava on the network to determine the user information associated with 
die noagnetic card. This infonnation may also be cached locally for improved effidency, as 
described in greater detail later in this document. Once the card has been coirectly read by the 
card reader 410 and identified (i.e., tfie data stored on the card corresponds to an active user of 
the system), the technician/user is presented wixh a logon screea on the display unit by tiie 

10 access control node 400, Jn the exemplary embodiment, the technician/user is prevented from 
entering a login name that differs from die login name associated with die data stored by the 
magnetic card. Accordingly, the technician is only able to input a PIN Qiersonal identification 
number - e.g., a password that, in the exemplary embodiment, may contain only numeric 
characters). Moreover, the technician may only enttt Ae PIN required to gain access within a 

15 configurable and limited time after the magnetic card has been read by the caid reado- 
410/access control node 400 and has been provisionally authenticated. It is expected that the 
time limit will, in many configurations, be set to 30 seconds. Accordingly, if the proper PIN is 
not entered within this 30 second time limit, the user will have to re-swipe their magnetic card 
in order to be provided with access the logon screen. Failure to enter the proper PIN within xhis 

20 time limit will, in xhe exemplary embodiment, result in the logon saeen be withdrawn from 
display and any input being rejected by the access control node. 

The access control node 400 then uses the combination of the PIN, the data provided by the 
magnetic card and the user directory server to determine whether the technician/user is an 

25 authentic user of the system (i.e., the magnetic card is active, the data is coiiect and the PIN 
entered by the user corresponds to the records maintained by the user directory server 
corresponding to the card swiped by the technician/reader). Also, upon input by the 
user/technician of login data (the PIN in the exemplary embodiment), the access control node 
transmits this event to the application 202, another aspect of the present invention. HIPAAT 

30 application 202 provides access control node 400 with access to centralised services available 
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via the netwoiic. In die exemplary onbodiment access contrDl node 400 accesses a centralised 
user direaory and a seciirity repository 102. 

The centralised user directory stores details about users (including, for example, active user 
5 accounts, the associated passwords and the access rig^s of those users to PHI and node 
functionality) and the nodes (including, for example, those nodes which are entitled to be 
connected to the network). Since a node may be disconnected fccm the networic (especially if 
the node is designed to be physically mobile), access control node 400 may, be adapted, to 
maintain a copy of die user directory locally. In this manner, acc^s to the functions provided by 
10 a mobile node may be provided while still ensuring the necessary security and protection of PHI 
stored on or generated by the mobile node. FIG. 2 includes an illustration of a local copy of user 
directory 206. 

Security reposirory 102 provides centralised storage of events for which an audit record has 
15 been created. Accordingly, security repository 102 may be queried so as to generate any 
necessary audit repon (assuming the user requesting such a rqpon has the necessary access 
rights to do so). 

In addition to providing user authentication (through die magnetic card and correct PIN input), 
20 die universal compliance module 200 also determines whedier die node 460 from whidi die 
user/technician has requested access is also authenticated. Node audientication is performed by 
appending a digital signature to every message sent to die HIPAAT application 202. The first 
message diat die node sends to die HIPAAT application 202 when it starts up will be checked 
by die HIPAAT application 202 using a pre-defined, stored key to determine die node's 
25 audientidty. Thereafter all messages received from die node 460 will be checked to determine 
diat th^ do, in fact, all ori^ate fi?om die same node. Assuming diat die node and user have 
each been properly audienticated, die HIPAAT application 202 determines die degree to which 
die user has been granted pemiission to access die various types of PHI diat are available for 
access from diat particular node and die PHI available to die user/wchnician. 

30 
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For example, and as noted above, the MRI scanner includes multiple input and output (I/O) 
devices. Furflier, the HIPAAT ^plication 202 will also deteraiine, based on the data associated 
with Ae user requiring authentication and the node 460 &om which access is being requested, 
those I/O devices for which the user will be provided access. Accordingly, assume in this case 

S that the technician has been granted peimission to review any patient's MRI scan that has been 
previously created or create (i.e., store) new MRI scans. However, die technician has not been 
granted peimission to print or store scans on a removable media. In dus instance, the HIPAAT 
application 202, having previously authenticated the user/te(^cian and die node (the MRI 
scanner), will use data or control signals to the control aspects of control node 400 

10 corresponding to die user's/technician's degree of permission. Based on die data or control 
signals about the technician's degree of permission, the access control node 400 will, ihrou^ 
both command signals and control of power (via switcher card 500 - also referred to herein as 
the VGA card), disable bodi die removable media storage device and the printer. The general 
purpose computer (i.e., the display, die input devices, etc.) and die analog monitor of the MW 

15 scaimo- will be accessible and usable by the tedinidan. 

Id addition to die foregoing, die access control node 400 and the HIPAAT application 202 work 
co-operatively to generate iaudit lop of activity at a node 460 associated witii die access control 
node. The audit logs will include data relating to bodi denials and grants of access. For example, 
20 if the magnetic card entered by a user had been previously revoked, no access to PHI will be 
granted. Despite a denial of access, the HIPAAT application 202, dirough its co-operation with 
the access control node, will still collect audit information. 

To belter understand diese and odier aspects of die preferred embodiment of die invention 
25 described above, greato- and more specific details are provided below. 
2. Definitions 
SR - Security Repository 
UCM - Universal Compliance Module 

HIPAA - Healdi Insurance Portability and Accountability Act of 1 996 

30 
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3. Product Description 
3.1 Product Concept 

A wide range of products will be required lo fulfil the tremendous need created by the new 
HIPAA regulations. One embodiment of the invention provides a complete **system*\ Althou^ 
5 a stand-alone system, it consists of a host of offerings Aat is available and can be implemented 
in various software modules and some hardware combinations including: 

1 . Software libraries that can be used with various operating systems (e.g., Witulows, 
Linux, and Unix platforms). This will allow a vendor's engineering depamnent to have 

1 0 control of development (at a fee), but not need to develop a solution finom scratch. 

2. Complete software modules Aat can easily be integrated into a purchaser's device. 
The vendor will define the supported platforms. 

3. Hardware/software systems ihat provide **ready-to-go*' solutions for the purchaser. 
These will be lura-key solutions require linle or no development or configuration on the 

1 5 part of the purchaser. 

Many hospitals and their suppliers will require unique solutions, making die task of developing 
a single solution more comply. Because many hospitals ahready have ''access control'' systems 
in place for physical entry to facilities, they may not be open to a new and different *'access 
20 conirol" device for their computer systems. Further, any new and/or different access control 
devices would, preferably, integrate with their existing systems. 

In accordance with one broad aspect of the invention there is provided a comprehensive system 
capable of satisfying various aspects of HIPAA compliance. The system is adapted lo connect to 
25 and communicate with hardware fiom a variety of suppliers (e.g., QE, Siemens, Hitachi, Fuji, 
etc.) simply, provide access controls (and other security issues), handle privacy issues, and 
create an Security Repository showing that the various activities were logged. 

4. Modules 

30 The following describes the modules included in the preferred embodiment- 
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4.1 Security Repository (SR) 

In the exemplary embodiment, the SR 102 (also referred to as the Archive Repository) is a 
stand-alone server comprising a database including a wel>-based interface. The SR 102 server 
receives logging messages from the devices on the network and decodes and stores these 
S logging event details in the database. As noted above, a separate web inter&ce allows an 
authorised user to query the database and produce reports. 

4.1.1 Archive Module 

Hie Archive module 104 archives the logging events and saves the data into the SR database. 

10 

4.L2 Reporting Module 

The Reporting Module 106 produces the query reports needed. (Note: User authentication is 
needed to produce reports.) 

15 4.1.3 Status & Alarm Module 

The Status and Alarm Module 108 tracks the status of all the registered access control nodes 
(described below), and generates a log and/or alarm if any unit feils to respond or is otherwise 
disabled. 

20 4.2 Universal Compliance Module rUCM) I 
As noted above, the UCM 200 fonns the software which controls the fiinctionaliiy of the access ! 
control node 400(FIG. 4). The UCM 200 controls the flow of information between a Digital 
Imaging and Communications in Medicine Standards (DICOM) workstation and the DICOM 
network and also controls access to the DICOM woricstation. The embodiment of the invention 

25 described herein also suppons workstations and equipment complying with additional and 
alternate standards including HL7 (i.e. Hospital Level Seven) standards. 

AS will be appreciated, the UCM 200 has, in the exemplary embodiment, been designed in a 
modular fashion. Consequently, many of the functions performed by UCM 200 (and, thus, by 
30 access control node 400) are embodied in a smaller, more easily managed, software components 
or modules. 
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4.2.1 Universa] Compliance Module Applicarion 

The UCM Application 202 (FIG. 2) (also referred to as the HIPAAT application) is the master 
program that controls ibe behaviour and resides on, the access control node, specifically 
5 stopping and starting components, displaying messages to the screen and logging users in and 
out Other components provide gateway communications, user directory access, data 
conversian etc. 

4.2.2 User Authenticator Module 

10 The User Autfienticaior Module 204 communicates with the User directory 206 to verify the 
usemame/magnetic card ID and password/PIN. In the exeR^>lary embodiment an authenticator 
API is provided to allow different types of authenticator modules to be later developed. This 
module will provide an authentication oveiride mechanism, so that emergency clinical actions 
can be taken, even when authentication is not possible or not successful. 

15 

4.2.3 Card Auflienticator Module 

The Card Auflienticator Module operates to query a user's card, token or other identification 
device that is employed (e.g., retinal scanner, fingerprint scanner, etc.). In the exemplary 
embodiment only the magnetic card readers are supported. 

20 

4.2.4 Logging API Module 

The Logging API module 208 provides a software library that accepts the logged events and 
queues and sends them to the SR 102. 

25 4.2.5 Network Gateway Mo4 nle 

The Network Gateway Module (or UCM Proxy) 210 intercepts DICOM network messages and 
analyses and captures audit information therefrom. This module also relays DICOM network 
messages received from or for the node for which a user has been properly authenticated. That 
is, the Network Gateway Module 214 operates to intercept DICOM message destined for and 

30 transmined by a node. These intercepted messages are only relayed to their intended destination 
(e,g., another pan of the network for DICOM messages originated fiom the node 460 or the 
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node itself for DICOM network messages addressed to die node) only once that a node and user 
have been properly audi^ticated by the UCM Application 202. 

4.2.6 User Directory Caching Module 

5 The User Directoiy Caching Module keeps a synchronized copy of user informaiion required by 
a node for use when the s)^te3n goes mobile and is disconnected fiom the netwoik. 

4.2.7 Switcher Control Module 

The Switcher Control Module 210 provides the digital outputs needed to control the switcher 
1 0 hardware according to role-based pennissions. 

4.3 Su pport Modules 

The following modules are provided by the exemplary embodiment to support the development, 
testing and demonstration of the HIPAAT syston. 

15 

4.3.1 User Directory 

The User Directory is provided if a user directory is not available by the information systems 
employed by the facility deploying anbodimoits of the invention (e.g., a hospital, health care 
campus, etc.). That is, a user directory (whidi includes a list of all users whidi have been 

20 granted various degrees of access to PHI, user passwoids/PINs, the PHI for which a user has 
been granted access and the type of access so granted - i.e., review, create, delete, store, 
disoibute, print, etc.) may already be in some information systems into which embodiments of 
aspects of the invention are being deployed. In this case, adding another user directory may be 
redundant. If such a user directory does not already exists, then one is provided. Such a user 

25 directory is prefiarably provided by a centralised storage fedlity so that this information 
accessibly by any of the nodes and die associated access control nodes 400. 
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5. HIPAA Compliance 



The following table describes security and privacy regulations as outlined by HIPAA. 



Pnactional 
Requirement 


HIFAA Requlremenc 


Embodiment of die Inveorion 


Audiiconirols 


Required under HIPAA "^Administrative and Technical 
Security Services to Guard Data Ini^ty, Confidennality 
and Availability**. Security and Electronic Signature 
Standaids, Proposed Rule. August 12, 1998, pages 43250, 
43269 and 43270. 


The UCM Application 202 stamps each 
activity with user ID, dace and time in 
addition to other extended audit control 
features of the database. 


Data Backup 
Mechanisms 


Required under HIPAA ""Administrative and Tedmical 
Security Services to Guaid Data Integrity, Confldemialiiy 
and Availability**. Security and Electronic Signature 
Standards, Proposed Rule, August 1 2, 1998, page 4325 1 , 
^vhich describes a "^daia backup plan". 


Unlises die standard database backup 
feature. It is the re^nsibiliiy of die 

mfidical Mtcrice U% ensure re<?u1fir ha^lrun^ 

are carried out as well as ensuring off site 
storage of sudi backups. 


Unique User IDs 


'Individual authentication of usei^*" is required undcar 
Hip AA '"fectinlcal Security Services to Guard Data 
Integrity, Confidentialiiy and Availability", Security and 
Electronic Signature Standards, Proposed Rule, August 12, 
1998^ j)age 43250. 


Tlie AufheAncAfion LiHrAiv 20d in 
cor\iunctzon with die Directory Server 
permits only unique user IDs. Unique user 
IDs are required to st^>pon adequate audit 
controls. 


OaiaSecuriiy 


Data security is required under HIPAA 'Technical 
Security Services to Guard Data integrity. Confidentiality 
and Availability*. Security and Elecn-onic Signature 
.Standards, ProiMsed Rule, August 12. 1998, oace 43254, 


Will secure critical information and the 
encryption of communicated data across 
the nctworit. 


Consent 
Mechanisms 


Informed, voluntary patient consent is required for certain 
PHI uses under HIPAA Standards for Privacy of 
Individually Identifiable HealA Information, Proposed 
Rul^ November 3^ 1999, page S9940. 




Mechaniflms to 
link or identify 
inctividual users 

entries in the 
eleorontc health 
record. 


It is unclear fix>m HIPAA if identification of individual 
users is required at the data level as is the case with paper- 
based health information. Under the "Technical Security 
services to uuora uaca integrity, LoniioentiaUty and 
Availability**, ^eariiy authentication" requires unique user 
identification along with a list of other implementation 
iisatures. Security and Electronic Signature Standaids, 
Proposed Rule^ Aufjusi 12. 1998. pa^c 43254- 


The Security Repository 102 stamps each 
aaivity with unique user id, date and time, 
which is then stored in the Security 
Repository. This fiinaion is available at a 
record level. 


Mechanisms to 

ii^ni\nritT<i1 
CMiVW liLlUIVlUUBI 

users to alter 
entries in the 
electronic health 
record without 
deleting previous 
(^clinicai| entries 


In so far as '"data audicntication** b a required technical 
security service under HIPAA, it may be inferred that such 
mechanisms tire necessary under die Act, Security and 
Electronic Signature Standards, Proposed Rule. August 12, 
1998, page 43254. 






Digital signamres can be inferred and may fisll under the 
l^iscr-based" access control requirement. HIPAA 
"Technical Security Services to Guard Data Integrity, 
Confidentiality, and Availability*' under the Security and 
Electronic Signature Standards, Proposed Rule, August 12, 
J99g_page 43254. 




Automaxic log-off { 

1 


Automatic log-ofEs are required under HIPAA See 
"Technical Security Services to Guard Data Integrity, 
Confidenuality, and Availability" under the Security and 
Electronic Signature Standards, Proposed Rule. August 12, 
I998,pa«e43254. 


The UCM 200, supports auixmiatic screen 
locking, network access control and 
automadc iog-ofiP of users. 
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Functional 
Recjalremenc 


HIPAARetiuirvnienT j 


Embodlmeai of the Inventiott 


Mechanisms lo 

individual parieni 
access xo personal 
healTh 
infbnnation 


Under HIPaA, patients wUI have access rights not only to 
their personal health information but also to organisational 
privacy and security policies. (Standards for Privacy of 
Individually Identi^able Health Infonnaiion, Proposed 
Rule, November 3. 1999). 


Patients can request r^rts of the Audit 
Log through operation of the Archive 
Module 104 and Security Repository 102 
penainins to their records. HIPAATis 
also able to provide electronic copies of 
documents and record whedier the patient 
has acknowledged them or not. By way of 
example, the Notice of Privacy Practises 



6. Detailed Design Description 

S This design description addresses the class A and class B requirements of Oie HIP AA that are 
supponed by the embodiment of the invention described herein. 

6.1 Security Repository (SR) 

10 In one embodiment of ihe invention, the only limit on the number of access control nodes 400 or 
gateways that can be connected to an SR is the size of the SR*s hard drive. A practical limit may 
be defined for performance testing of simultaneous transfer, as well as database size for audit 
events. 

In one embodiment of the invention, the Security Repository employs standard Linux server 
15 components; 

• Computer Operating System 

- SQL database 

- Web server 

- SSL encryption library 
20 - Web scripting 

A Digital Certificate module (capable of creating, storing and managing digital certificates) is 
installed in the SR to suppon the secure transfer of information between the UCM units/servers 
and the SR as well as for secure web-based (HTTPS) access. 

25 Referring to FIG. 1, a block diagram illustrating audit response modules in accordance with an 
embodiment of the invention. 

6,l.l Archiye \f odule 
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The following describes die archive module 104 in one embodiment of the invention. 

The SR 102 software uses a database such that advanced queries can be performed on the audit 
data. The database may be a conventional relational database supporting the Structured Query 
5 Language (SQL). For example, the IBM DB2 Universal Database, PostgreSQL, Oracle 
Database or Microsoft SQLServer, could be employed in various embodiments of the invention 
described herein. 

The amount of audit entries on the SR 102 could easily be in excess of millions as large 
10 numbers of personnel access various types PHI from the nodes of a health care centre. In some 
embodiments the SR 102 has been adapted to provide for ftie easy location of specific 
information. In these embodiments, the search capabilities of die database employed to provide 
some of the functionality of the SR are made available for users to search for particular 
information. This search functionality is preferably provided through a easy-to-use Graphical 
15 User Interface (GUI) for those users performing ad hoc queries or for novice users. A command 
line interface or compiled SQL queries may be preferred for those queries that are often 
repeated or for more advanced users of the searcdi functionality. 

For example, two exemplary searches are provided: 

20 

1. Searches a '^selected patienf* file and provides a chronological summary of all trigger 
events for any chosen period 

2. Search by a ''selected User'' and provides a chronological summary of files accessed for 
2S any chosen period. 

The SR 102 software provides a warning when the hard drive storing the audit database has 
reached 75% capacity. In some embodimmts, diis threshold is configurable and may provide for 
the storing of the database across multiple physical or logical drives. 

30 



Page 20 of S3 



16-2003 15:29 



FROM-PASKEN MARTINEAU 



4163647813 



T-852 P. 003/003 F-37I 



ARomey Dodcat No. 3342046.00M 



In die preferred embodiment, the SR 102 software provides a mechanism to archive older events 
to free up space in the database. That is, older audit infoimation may be moved from a hard 
drive to a cheaper storage alternative (e.g., tape storage, DVD, etc.). 

S The mechanism may store older events to an archive. In an altonative embodimoit, an option 
may be provided for an archive that will be used for long-term audit trail backup. An on-board 
DVD in the SR 102 may be provided to facilitate this long-term backup. 

The SR 102 software additionally is adapted to provide users widi the opportunity to view 
10 archived events from long-term storage (e.g., tape or DVD storage media) without restoring 
^ese events to the quicker, network accessible hard drive storage. This fLmctionality allows a 
user to review audit events to assess whether these events should be transferred back to the hard 
drive from long term storage. 

1 5 The SR 102 software also provide a user with die ability to merge an archived database with a 
current database. This fimctionality of die SR 102 software leverages die ability of known 
relational databases to access repositories of data across different media types (e.g., hard drives 
and tape storage). 



20 The database used by the SR 102 software provides support data integrity tools to minimise die 
chance of data corruption/loss. The relational databases identified above provide this 
functionality to various degrees. 

The database used by die SR 102 software has been selected to sustain sudden loss of power 
25 without data corruption/loss. 

In some embodiments of the mvemion, die information described below is captured for every 
log record. This information will be recorded in die database employed by die SR 102 software. 



30 



Each activity is provided with a globally unique identifier gjvai it 
by the device creating the event. The globally unique will 
eliminate ambiguity and provide for dispibuted cross-referencing 



Unique Activity identifier 
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of events. In the embodiment the ^obally unique identifier is 
automatically generated programmatically for each audit event (or 
activity) that is lo be stored in the database 


Link Activitv identifier 


*• **** awiiviijr 49 uiivvujr iwiatwu vu cipivViUU^k owiiViiyj ulcn ullS 

field will provide the backward reference, (Obviously, fliere can 
never be such a thing as a forward reference). The link activity 
identifio' may be, for example, ihe inclusion of the unique activity 

column in a relational database table. 


Date and time of the activity 


Every activity must be ordered according to the system-wide 
clock. Although it may not be possible to perfectly synchronise all 
devices., the timestamn. ui the nreferred embodiment I'c a1wav« 
greater than that of any other network message already received. 


Validity time/duration 


Used to assist clean-^uo of the database 


Soiirce identifier/signature 


This is the identifier of the machine used to produce the activity 
loc entry. In one embodiment, the MAC address of the node that 
is the source of the activity is used- 


Owner identifier 


This is the identifier of die owner of the inforaiation reported by 
the activity log, (e.g. the patient). 


Audit data 
(from XML) 


Activity log details - activity dependent as specified by IHE. 


Auihorised user 
identifier/signature 


This is tiie identifier of the user generating the infonnation. If 
possible, it will also contain a digital signature from the process 
that validated tiie user, providing some guarantee that the 
validation process was, in fact, carried out. Accordingly, in flie 

embodmient de^crihed Viprem a imimip id^ntifipr rhA tic^ te 

maintained by the Authentication Library in conjunction with the 
HIPAAT Server which permit only unique user IDs. A digital 
signature generated by the Authentication Library indicating that 
the user has been properly recognised and authenticated is also 
preferably stored. 


Log digest/signature 


This acts as a secure checksum on the data, allowing ihe recipient 
to authenticate the source of the data and to v^iy that the data has 
not been corrupted. 



6.1.2 Reporting Module 

The following describes the reporting module 106 in some embodiments of the invention. In the 
embodiment described herein a web-based report access and generation function is provided by 
the Reporting Module 106. The web-based reports are only accessible to authenticated Audit 
users. That is, users wUl have to be logged in and have capabilities (i.e., peratissions) to access 
the logs. Given that web browsers have become ubiquitous on numerous types of devices (e.g., 
personal computefs, personal digital assistants, wireless devices such as mobile telephones, 
etc.), a web-based report access and generation fimciionality enables a very large number of 



Page 22 of 53 



NOV-18-2003 15:17 FROM-FASKEN MARTINEAU 4163647613 T-851 P.030/081 F-370 

Anomey Docket No. 3342046.0004 

nodes to gain access to this important data (assuming, of course, that bodi the node and the user 
accessing the node have been properly authenticated). 

The web-based reports provided by the Reporting Module 106 of the system described herein 
5 generally ^1 into four main categories: 

1 . Per-patient reports: This report shows all of the events for a particular patient. 

2. Per-user repon: This report shows all of the activities for a particular technician or 
physician (i.e., for a particular user). 

10 3. Ptt- date/time period: This repon shows events for the period selected by a user (e,g., a 
specific date, a specific time or a range of dates and/or times). 
4. Per audit event: This report shows all of the patients that have been aflfected by a specific 
audit event For example, a rq)on could be generated that will identify each patient that 
has had their PHI access for a particular type of audit event (e.g., have had their 

15 accounting information accessed). 

In addition to the above categories or filters (singly or in combination), there is provided sorting 
by date^e, by patient and by user. This fimctionality is provided in the exemplary 
embodiment throu^ access to pre-written queries thai are performed by the Rqwrting Module. 
20 The results of these queries are then formatted by the database into a web page format. An 
authenticated user can then use the generated report. As will be appreciated, the reporting 
module wiU also allow the audienticaied user to view the status of flie access control nodes 400 
remotely. 

25 The SR 102 software uses a database such that advanced queries can be performed on the audit 
data. In the exemplary embodiment, the SR 102 software employs a conventional relational 
database that provides the advanced queiy firactionality of the audit data stored in a repository 
by the SR 102 software. As will be appreciated, die amount of audit entries on the SR could 
easily be in excess of millions of records. Accordingly, a relational database which provides a 

30 mechanism the for the easy location of specific information is highly desirable. 
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Two exemplary searches are: 

1 . Searches a "selected patieni" file and provides a chronological summary of all 
trigger events for any chosen period 

5 

2. Search by a "selected User** and provides a chronological summary of files 
accessed for any chosen period. 

6.1.3 Status & Alarm Module 
10 The following describes the status & alarm module 108 in some embodiments (including the 
preferred embodiment) of the invention: 

The Security Repository (SR) 102 will register fte status of the access control nodes 400 
through network communication, and p^odically verify this status. If die verification Ms 
IS (i.e., a selected access control node does not provide a response to a stams inquiry transmitted 
by Has SR), an alarm will be issued by Ae SR 102 by way of an on-screen message. Data 
corresponding to die status of flie access control nodes 400 in a system will be available to the 
Reporting Module 106 for displaying to remote web users. 

20 In one embodimem of the invention, there is provided int^ration with simple network 
management protocol (SNMP). 

The SR 102 logs die inability to communicate with the access control node 400. Failure to 
communicate with an access control node 400 results in an alarm or other warning indicative of 
25 die failure of an UCM. The status and alarm module 108 allows a system administrator to be 
informed of the status for all access control nodes 400. 

In the exemplary embodiment, the status and alarm module 108 software runs in the background 
on an administrator's machine. Moreover, the status and alarm module 108 provides to an 
30 administrator a visual warning that one or more access control nodes 400 is unresponsive to 
staws inquiries. In die exemplary embodiment, the stams inquiries to each of die access control 
nodes 400 is provided through the SR 102 ^-ping'^ing each access control node 400 periodically. 
The software should be configurable to display a "popup" any time an access control nodes was 
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not protecting its intended device. Since the access control nodes are &il-safe ih y are 
designed to M in a way that permits clinical activity rather than prevents it. Preventing activity 
may be more intuitive but is generally not acceptable in a medical enviromnent. 

5 In the exemplary embodiment, the SR 102 operates to prevent a user to remotely logon or into 
to an access control node 400 if that user has already remotely logged into a diffei«it access 
comrol node. Note that if die access control node is in poiuble mode, tfi^e will be no way of 
knowing, and therefore, the login should be allowed. ^Portable' is used to describe equipment 
diat is carried or wheeled around, typically to a patient's bedside or perhaps shared between 
10 departments. In many cases the netwoilcs are disconnected to do this and reconnected when the 
equipment is retumed. 

6.2 Universal Comnhance Module fUCM^ 

1 5 The UCM unit includes a mechanism to prevent viruses from affecting software performance, hi 
the preferred embodiment, this virus prevention mechanism may include a conventional 
enterprise level virus detection and removal software. 

Referring to FIG. 2, a block diagram other aspects of die access control node 400/gateway 
20 modules in accordance with an embodiment of the invention are illvsurated. 

6.2.1 User Audienticator Module 

The user audienticator module 204 in the embodiment of die invention described herein 
25 provides for die audioaiicaiion of a user desiring access to PHI fiom a secure node and, if 
authenticated, the access rights (i.e., permissions) of die user to die requested PHI. 

User-based access to die a workstation 460 (e.g., a DICOM workstation) and die network 212 
will be governed by: 

30 - Successfol audientication of die user (e.g., an active magnetic card togedier widi the 
correct password or PIN). A user directory will be used lo audienticate die user 
credentials. 



Page 25 of 53 



NOV-18-2003 15:18 FROM-FASKEN MARTINEAU 4163647813 T-851 P.033/081 F-370 

ARomey Docket No. 3342046.0004 

- User access rights, which wUl be obtained from ihe directory server 206. The user access 
rights determines not only tiie infonnation to which the user has been granted 
access/permission but also limitations on what the user may do with that infonnation. 
For example, a user may be granted to access to an MRI scan of a selected patient (i.e., 
5 the user has been granted access or permission to this data). Additionally, the tiser may 

be have limitations on the operations that can be perfonned on the data to which access 
has been granted. For example, the user may be prohibited from making a copy of the 
data (in a tangible or electronic format - i.e., no printing, no saving of an electronic 
copy, no transmission). 

10 

Retrieval of Audit infeimation will be controlled according to the user's directory entry. Such 
access will be granted independently of DICOM woricstation access. 



Role-based access is a feature that allows the clinical organisation to implement policies that 
15 control the usage of PHI. The produa supports the following roles: 

- Auditor able to access the audit logs 

- Disdosen able to print, forward and expon PHI 

- User: able to create and view PHI. 

While du:ee (3) such roles are described above, persons of ordinary skill in the art will 
20 appreciate that other roles could be additionally or alternatively created depending upon the 
environment and needs of user into which an embodiment of the invention has been deployed. 

Each user, to fecilitate ease of administration of a system embodying this aspect of the 
invention, will be assigned to one or more roles. Each role wUl have certain permissions and 

25 limitations placed on any PHI thai are to be accessed. A user will then be assigned to one or 
more of these roles. For example, it may be desirable to create a "Physician" role and grant to 
users that have been assigned to this role the right to access any medical related data in ihe PHI 
for any patient in the system. Additionally, the Physician role would have the ability to create, 
print, forward and export PHI but not to delete any PHI. Accordingly, rather than re-creating 

30 permissions and limitations for a new physician being granted access to PHI, the new physician 
can be assigned an account that has been granted the role of Physician. 
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Tlie UCM software (Le., application) allows role-based access options. The defined roles in the 

exemplary embodiment are as follows: 

User Defines the ability to create, modify, delete Oocally) and import PHI. A User may 
also send PHI to pre-detennined redpients, such as an image archives. 

5 

Discloser: All the capabilities of the User, but in addition a Discloser has the ability to 
send PHI to a wide range of recipients and to export PHI in a variety of different 
fonnats. (e.g. create a CDROM of the PHI or send the PHI to a netwoik printer) 



10 Auditor: This role provides all the capabilities of the Discloser and in addition pennits 

access to repons on PHI usage and on system status. 

The automatic logout time for Ae UCM is configurable. After a time equal to the automatic 
logout time has elapsed since a user has last perfbnned an activity (e.g., accessed some PHI 
15 data, created PHI data, etc.), the user is automatically logged out by the HIPAA gateway. This 
will result in the access control node interposed between the node and the UCM preventing any 
further access to new data or operations to be performed on data that has been previously 
accessed and was in the procos of being processed (i.e., operated on) by the user at the node. 

20 hi &e exemplary embodiment Ae automatic lo^ut time is configuiable in minutes to 10, 15, 
20, 30 (default), 60 minutes, or off (i.e., this functionality is disabled and a user will not be 
automatically logged out due to Ae lapsing of time). 

Any network activity from the device that the access control node 400 is protecting (i.e., the 
25 UCM software is communication with a node through the physical connectivity provided by the 
access control node) resets the timer that is monitoring activity for automatic timeout. 
Consequently, whenever there is network activity between the node and the UCM, ihe timer 
used for automatic logging out of a user will be reset to zero. The timer will then commence 
marking time untU either more network activity is detected (at which time the timer will again 
30 be reset to zero) or the automatic logout time threshold will be set (if it has not been disabled). 



Page 27 of 53 



NOV-1 8-2003 15:18 



FROM-FASKEN MAfiTINEAU 



4163647813 



T-8SI P. 035/081 F-370 
Anomey Dockei No. 3342046.0004 



When the UCM software detects tfiat Ae aummatic timeout limit has been reached, the UCM 
software logs the user out 

When the UCM software detects that the automatic timeout limit has been reached, the UCM 
5 software infoims the user that the maximum inactivity time has been reached, and that they 
imist login again. 

Referring to FIG. 10, a line diagram illustrating card reader riming in accordance with an 
embodiment of the invention is iUustiated. As persons of ordinary skill in tiie art will appreciate, 
10 each of tiie time limits described below can be configured to satisfy the needs of the users of the 
^bodiment of ihs present invention. 



Time 
parameter 


Description 


Typical setting 


tl 


Card validation interval - card must be present in reader 
or card must be inserted/swiped again. 


10-30 minutes 


t2 


Maximum time between inserting the card and entering 
the PIN, Failure to enter a PIN within a time 'H'' will 
result in the user having to insert/swipe their card again. 


30 seconds 


t3 


PIN validation interval - card must be present in reader or 
card must be insened/swiped again and PIN must be 
entered. If this feature is configured as operational, a user 
must enter their card and PIN after the configured time, 
^'tS" has elapsed regardless of the amount of time which 
has elapsed since the last event/activity. 


1-3 hours 


i4 


Auto logout time - time since last activity (keyboard, 
mouse event, network activity). If configured to be 
operational this feature will automatically logout any user 
if there has been no activity in the past **t4" time period. 


5-20 minutes 


t5 


Grace period - user is warned that the session will be 
ending. This feature works co-operatively with the auto 
logout feature. 


30 seconds - 3 
minutes 



In one embodnnent of the invention, the SR integrates "Role Based Access" software to allow 
user access only to the aufliorised level. 



6.2.2 Caid Reader Mrvli^l t. 
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The following desoibes the card reader module in some embodiments of tiie invention. 

In one embodiment of the invention, the reader will require magnetic card insertion and aitry of 

a PIN on the keyboard or other input device. 

5 The access control node 400 includes the ability to provide user authentication by using a 
magnetic ID Card in conjunction with a PIN or other password type. A card proximity device 
may also be used as opposed to card swiping. After entering both card and PIN successfully, 
only card (no PIN) is required for re-login following a normal logout (i.c, pushbutton or card 
proximi^). An auU>matic logout occurs when inactivity (no netwoik tra£5c) exceeds the 
10 allowable time (configurable in minutes to 10, 15, 20, 30 (default), 60, unless this feature has 
been disabled). After an automatic logout, the uso: must enter card. The card-only login time is 
limited to a configurable time of 8, 12 (de&ult), or 24 hours (or ofiQ, after which time the card 
and PIN combination is required. 

15 As persons of ordinary skill in the an will appreciate other forms of identification could be 
employed. For example, RFID tags or fingeiprint or retinal scanners could also be employed. 

6.2.3 Logging API Module 

The following describes the logging API module 208 included in the preferred embodiment of 
20 the invention. 

The logging API module 208 will present a programmatic inteiface based on the parameters 
required for each log event. This module will format the logguxg messages according to the 
XML schema defined in the IHE spedficaiion, and transmitted to the SR 102. This module 
25 siq)pons encryption, content certification (signing), queuing, transport and ttacing/debugging. A 
private encryption key will also be installed for use by this module in order to sign the log 
messages. 

When offline, the UCM software queues all audit trigger events, such that they can be 
30 transferred to the SR when a re-connection is made. 

6.2.4 Netwoik Gatcwav Module 
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The following describes die netwoik gateway module 204 the preferred emhodimeat of the 

invention. 

Audit events are detected by monitoring of DICOM TCP/IP messages by Uie networic gateway 
5 module 204. In the exemplary embodiment, the exception to this will be the analog print 
triggers, which will be detected by the Switcher Control module. 

The UCM software prevents other devices on the network 212 from having access to Hhe node it 
is protecting. Additionally, the UCM software prevents die node to whidi its associated access 
ID control node is connected from having access U) the rest of the network. However, the UCM 
software does not affect the data diat passes through it in any way. 

In die exemplary embodiment, the UCM software is furdier adapted to SSL-encrypt all non- 
SSL-encrypted PHI for electronic transfer and accept SSL encrypted or unencrypted DICOM 
15 data. 

6.2.5 Directory Caching Module 

The following describes the directory caching module 206 in the embodiments of the invention 
described herein. Caching of the direaoiy is needed in order xo suppon **mobile operation" of 
20 the units. Mobile operation of die access control node involves die operation of the access 
control node during a period when the node and its associated access control node have been 
disconneaed from network. Such a disconnection may be intrational or unintentional. 

Referring to FIG. 3, a blodc diagram illustrating directory caching in accordance with an 
25 embodiment of the invention. 

The UCM software is ad^ted to allow user authentication when in portable mode (not 
connected ro die network - intentionally or unintentionally). Prior to mobile operation, die UCM 
software will download a list of all possible users. The downloading, in die preferred 
30 embodiment, is performed whenever die access control node connects to die central 
audientication database residing on die SR X02. The access control node 400, duough operation 
of the directory caching module, will update its list of users periodically (e.g., daily, upon start- 
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1^, etc.). In general, there is no need to push the User List to all access control nodes 400 when 
a new user added. 

The Directory Caching module will update the local cache at predefined intervals (e.g. daily, 
S upon start-tQ), etc.). 

Configuration parameters for the UCM software will be stored in a hospital directory server or a 
central directory server provided if the hospiud does not have such a server. 

1 0 6.2.6 Switcher Control Module 

The switcher conirol module 210 in die preferred embodiment of die invention provides die 
inter&ce to the Switcher Cards (described below). The switcher control module 210 includes 
outputs for the power modules, the video relays, the analog printer trigger signals, and 
emergency override control. 

15 

The UCM software is adapted to interrupt the flow of a video signal lo the device to which it is 
connected. The UCM software interrupts the flow of the video signal throu^ control of 
Switcher Card SOO described in greater detail below. 

20 The UCM software is adapted to di^lay video that it generates back onu> the screen of the 
device to which it is connected. For example, the UCM software may be connected to diagnostic 
device (e.g., an MRI scanner, a general purpose computer, etc.) that includes a video display 
(e.g., a CR, a flat panel display, etc.). The UCM software is adapted to generate a signal which 
is then transmitted to the device with which it is connected (i.e., associated). This signal may 

25 result, for example, in a logon screen allowing for messages to be presented to a user. An 
inter&ce to video switcher hardware may be used to provide this functionality. 

When ttie UCM software detects fliat die automatic timeout limit has been reached, die UCM 
software ensures diat any video signal coming fiom die device it is associated with (i.e., 
30 protecting fiom non-secure or unauthorised use) is no longer displayed on die screen of die 
associated device. 
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The UCM software is adapted to control the Switcher Control Module 210 such that each powa 
receptacle at a node can be individually controlled (power on or off) and data streams can ei&er 
be allowed to be passed to or from the other I/O devices of the node. 

5 

The UCM software includes a configuration program l3aax is used to set the on/off status of ea<^ 
receptacle. The default for each receptacle is on. On powa i^, the UCM software sets the 
Switcher Control Module 210 to the last saved configuration. The UCM software is also capable 
of controlling all outputs from the Switcher Card SOO individually. This capability is required to 
1 0 suppon authorisation and role>based access. 

6.2.7 Fail-SafeOperarion 

In the clinical environment, the most important aspects of the apparatuses employed are: 

- Safety of the patients (and caregivers) 
15 - Unimpeded clinical activities 

- Integrity of PHI 

Therefore, should Mure of an apparatus occur, regardless of whether this is through design 
error, hardware malfunction, accidental or deliberate misuse or some exttmal &ctor, the 
20 delivery of patimt services should not be impeded. Funfaennore, information akeady acquired 
by the apparatus will not be lost or compromised. 

In addition to this, an override mode will be provided. This is intended for use in emergencies 
where the normal operation of the system must be overridden to allow woricstation access 
25 without proper user authentication. Selection of this operation will immediately trigger a 
system alarm and notify the system administrator. All DICOM operations will still be logged, 
however. 



6.3 Support Modules 

A number of modules are required or used to facilitaie development, testing and demonstration 
of the HIPAAT Product. The following describes some embodiments of these modules. 
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6.3.1 User Directory 

A simple user dixectory will be used to store die configuration and user information. Access to 
the directory will use the well Icnown LDAP protocol, and one server will serve as the directly 
5 master. 



6.3.2 Information Required from the Directory 

ObjectClass = HIPAAT user 
cn=»<username> 
dn=<distinguished name> 
IDCardNumber=<MDS mag. card number digest> 
PIN=<MD5 password/Pm digest> 
PublicKey=»<PubUc encryption lcey> 
UserRole= Yes| 1 |No|0|<NULL> 
AuditRoIe= Yes|l|No|0|<NULL> 
DisclosureRole* yes|l|No|0|<NULI;> 
La5£Name=<last name> 
FirstName=^first name> 
e-mail=<e-majl address of user> 
ielephone=<phone number> 
pager=<pager number> 

Runtime data: 

Client=<worstationID>|<NULL> 
LoginTime=<date/tim6>|<NUIX> 
Created=<date/time> 
UpdaTed'=<daie/time> 

ValidUntil=<date/time>|<NULL> // <NUL1> means invalid ' 

The Security Repository 102 device stores all authentication infomiation such that login 
10 infonnation changed for a user becomes efifective for all access control nodes 400. User set- 
up/maintenance may be done at the SR. 



7. SummnY Y 

The invention described above covers at least some of the initial requirements for HIPAA 
1 5 security and auditing for an add-on solution to existing equipment: 



Page 33 of 53 



NOV-16-2003 15:19 FROM-FASKEN MARTINEAU 4163647813 T-BS1 P. 041/081 F-370 

ARomey Docket No. 3342046.0004 

1. Access control to equipment and the netwoik is restricted to authorised users based on 
predefined roles. 

2. Access to the equipment is captured and logged. 

3. Access to PHI (DICOM events) is captured and logged. 
S 4. Auditing of the logs is supported via web-based r^ns. 

Refeiring to FIG. 11, a flow chart 1100 illustrating directory caching logic in accordance with 
an embodiment of tiie invention is ilhistrated. 

1 0 FIG. 12 illustrates an exemplary listing of a XML log evm in accordance with an embodiment 
of the invention. 

FIG. 4 is a block diagram illustrating an exemplary data processing system or access control 
node 400 in accordance with an embodiment of the invention. The access control node 400 
includes an input device 410. a central processing unit or CPU 420, memory 430. a display 440, 

15 an output device 450, and a VGA switch 500. The input device 410 may include a keyboard, 
mouse, trackball, magnetic card proximity device, PIN input device, or similar device. The CPU 
120 may include dedicated coprocessors and monory devices. The memory 430 may include 
RAM, ROM, databases, or disk devices. The display 440 may include a computer screen, 
terminal device, or television. And, the output device 450 may include a CD-ROM, a floppy 

20 disk, a printer, or a network connection. The VGA switdi 500 is coiqaled to each of die CPU 
420, an external console 460, and an external monitor 470. The external console 460 may be a 
medical imaging computer or system. The external monitor 470 may be a computer screen or a 
medical imaging system display monitor. The access control node 400 has stored therein data 
representing sequences of instmctions which when executed cause the method described herein 

25 to be performed. Of course, the access control node 400 may contain additional software and 
hardware a description of which is not necessary for understanding the invention. 

FIG. 5 is a printed circuit board layout diagram illustrating a VGA switch 500 in accordance 
with an embodiment of the invention. The VGA switch 500 may include a CPU, memory, 
30 relays, indicators, and conneaois. FIG. 6 is an exemplary bill of materials for the VGA switch 
500 of FIG. 5. And, FIG. 7 is a schematic diagram for the VGA switch 500 of FIG. 5. 
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Refening to FIGS. 4-7, in accordance with xhe method of the present invention described above, 
the VGA switch 500 is controlled by the access control node 400 to connect the external console 
460 to the external monitor 470. When the VGA switch is closed, it allows VGA and/or other 
5 signals to pass from the ^eternal console 460 to the external monitor 470 for display to a user. 
When die VGA switch is open, a VGA logon message is generated by the access control node 
400 and displayed on the external monitor 470 via the VGA switch 500. The open/dose status 
of die VGA switch 500 may be controlled with a non-secure method by the access control node 
400 or through a secure logon procedure controlled by the access control node 400. With die 
1 0 non-secure method, a user may control tiie status of the switch 500 by making a universal PIN # 
entry. In the secure mode, the access control node 400 may, for example, present a logon screen 
to tiie user via ihe external monitor 470 and/or display screen 440 and/or a PIN input device 
410. To logon and close the switch, the user would have to enter a valid password or PIN as 
directed by the logon screen. Additionally or alternatively, a card access syston could be used. 

15 

FIGS. 8, 9(a)-9(d), and 13 are wiring diagrams illustrating an alternate switdi 500 in accordance 
with an alternative embodiment of die invention. The alternate switch may be used to switch 
multiple signals including I/O signals (e.g,, video, audio, printer, or the like) and/or power 
supply lines to external devices, for example, a VCR or other removable media devices. 

20 

As mentioned above, the network gateway module ihonitors DICOM network messages, 
capmres audit information, and relays this information to a Security Repository 102. These 
DICOM messages may be monitored, for example, as ih^ pass from a first external console 
470 to a second external console 470 through a switch 500 and/or as they pass through the 
25 network 212. The network gateway module 214 of the access control node 400 ciqitures 
information (through operation of DICOM decoder 216) from DICOM messages, formats this 
information as XML documents, and sends the resultant XML documents to a repository 102 for 
subsequent processing and use by audit applications. The invention supports messages 
complying with additional and alternate standards including HL7. 

30 
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As will be appreciated by those of ordinary skill in the ait, die present invention may be 
embodied in software or data instructions. This software, described above, may comprise more 
than one software module, that will, when executed by one or more access control nodes (e.g., a 
computer - whedier personal or server, or other forms of computer processing devices), adapt 
5 the access control nodes to perfonu some or all of the functions described herein. For example, 
a UCM may be embodied in software that when loaded into and executed by a computer or 
con^uter server, ad^ts the computer or computer server to perform those functions described 
heron attributed to ttie UCM. As a fiirth« consequence of some or all of ihe flmctionality 
described herein being embodied in software, the software may be transported to users by way 

10 of a computer software product (e.g., a physical storage medium such as a diskette, CD, DVD, 
hard drive or the like). Similarly, given the nature of communications networks, this same 
software may be transported to a user electronically through transmission over one or more 
commimications network rather than delivering a physical media to a user. Further, as will be 
appreciated by those of ordinary skill in Ae art, rather than embodying the invention in software 

15 or transporting/transmitting this software via a physical computer software product or over a 
communications netwoiic, aspects of Ae invention could also be embodied in an integrated 
circuit product including, for example, a coprocessor or memory according to an embodiment of 
die invention. This integrated circuit product can be installed in a computing device to perform 
die functionality of the access control node described above. 

20 

The interaction of a user with the various components described above and the interaction of 
those components with each other is best understood widi reference to FIG. 2. To undostand die 
interaction of &ese components an example will be used. The ^cample consists of an operator 
attempting to gain access to some PHI from a node (e.g., an MRI Scanner) fonning part of 
25 system 200. 

fiutially the operator desiring access to die node must access the access control node 400 (not 
shown) which includes a video display, keyboard (or keypad) and a card reader. Additionally, 
but likely unseen by die operator, access control node 400 includes a hardware switcher card 
30 and a mechanism for connecting to and communicating with die network and any centralised 
services. This mechanism, in most circumstances, is embodied in a communications network 



Page 36 of S3 



NOV-I 8-2003 



15:19 FROM-FASKEN MARTINEAU 



4163647813 



T-85I P. 044/081 F-370 



Attomqr Docket N . 3342046.0004 

inter&ce card such as an Ethernet card or a wireless netwoiic communications card. The video 
display is initially blank until die operator swipes or enters thtir magnetic card in or through the 
card reader. The access control node operates to read the card E) infonnation stored on the card 
through control of the Card Audienticator Module. This will result in the access control node 
5 displaying a PIN entry screen (i,e,, a logon screen) whaein the operator is prompted to enter, 
via the keyboard, their PIN. 

Upon receipt of card ID, PIN and node ID data, the HIPAAT application will perform two 
primary operations: (1 ) \iset and node authentication; and (2) audit log creation. 

10 The card ID, PIN data and node identification data is used by the HIPAAT application 202 to 
authenticatt the user and node from which access is being sou^t by the operator. The HIPAAT 
application 202 will, through control of the user audienticator module, communicate witii the 
user directory (which may be local or centralised). The authenticator module, using the 
authentication API, will determine whether the card ID is valid and, if so, whether the PIN data 

15 entered by the user conforms with the PIN data stored in the user dii«ctory associated with the 
card ID also stored therein. That is, if the card ID is valid (the card contains data for a valid 
account), the authenticator module determines whether the operator ens&ei the correct PIN 
data. In the exemplary embodiment, the PIN data will be transmined from the user directory 
(which may be local or centralised) to the HIPAAT application 202. This received PIN data is 

20 then compared against the PIN data entered by a the operator. If the PIN data entered was not 
collect or if the card ID was not associated with a valid account, the HIPAAT application 
202detennines tius state based on the received user PIN data. If the PIN data entered was 
correct, the HIPAAT ^plication 202 also detennines this state and, additionally, receives data 
indicative of the operator's permission to access data. This latter data is keyed or linked not only 

25 to the user but also to the node from which the operator has sought access. In the exemplary 
case, the data renimed to the HIPAAT application 202 in response to an attempted user logon 
will indicate, for example, that the operator is entitled to view MRI scans but not print or store 
to a removable media. The HIPAAT application 202 is also provided with a userlD that 
uniquely identifies the operator attempting to access PHI. 

30 
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Based on the data received by the HIPAAT application 202 from the user authenticator module, 
control signals will be used to control the access control node 400. The access control node, 
responsive to the control by the HIPAAT application, will operate to either prompt the user for 
the correct PIN (assuming the card ID and node ID is valid), shutdown the associated node (if 
5 either the card ID or the node ID are not valid - e.g., the card has been terminated, the node is 
unrecognised, etc.) or selectively allow the operator to access some or all functionaliQr provided 
by the node. In ihe ^emplary case, the MRI scanner (which includes a display, a keyboard, a 
printer and a removable media drive - e.g., an extenud DVD-RAM or DVD-R drive) will only 
be partially powered allowing only partial access. The access control node provides Oiis 
10 selective control by providmg power to those portions of the MRI Scanner \bai the operator has 
been granted permission (e.g., the core of ±t unit enabling the viewing or creation of scans) but 
not its peripherals (i.e., the printer and the removable media drive are not provided with power). 
This selective powering of aspects of the node is provided through operation of the switcher 
control card which fonns part of the access control node. 

15 

Regardless of whether access to PHI was granted to die operator as described abov^ the 
HIPAAT application 202 perforais a second fimction, event log^ng. An attempted login (which 
was defined above as a *'usct authotticaied" evoii) will result in the HIPAAT application 202 
requesting storage of an event. The storage of event is initiated by the HIPAAT application 202 

20 through access to the functionality of the Logging API Module 208 (described above). By 
passing data (e.g., die userlD infonnation previously received or the cardID information if the 
operator was not authenticated by the user authenticator module; the time and date; and the 
nodelD; etc.) to the logging API 208 an XML event (similar to the one illustrated in FIG. 12) is 
created and digitally signed by the HIPAAT application 202. This digitally signed event log (in 

25 XML format) is tbea entered in an event log queue. The events in the evait log are then soit 
(individually or in batches) to the Security Repository server (SR server) 102. In an alternative 
embodiment, the SR server periodically inspects die event log for new events ra&er than having 
Aese events transmitted to the SR server automatically. 

30 The (SR server) upon receipt of a new event log will store the event in the SQL database 
through access to die functionality of the Archive Module 104. The transmission of the event 
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log to the SR server may employ any suitable communication protocol. However, in the 
preferred embodiment die HIPAAT application 202 and SR 102 communicate using secure 
HTTP (HTTPS) to ensure a level of security. 

S As will be appreciated by those of ordinary skill in the art, the user and node authentication and 
the event logging can be performed serially or, as in the embodiment described herein, in 
parallel. 

Once user and node authentication has been completed, an operator may then attempt to perfoim 
10 various activities (i.e., events) in accessing, creating or deleting PHI. In the exemplary 
embodiment, the operator attempts to perform various events involving PHI through an MRI 
scanner which communicates with the domain using die DICOM protocol. Consequently, 
DICOM packets will be transmitted to and from die node as a result of the operator's input. In 
the prefenred embodiment, packets transmitted from die node to die network are first intercepted 
15 by an UCM proxy 214. The UCM proxy 214 also imercepis DICOM packets destined for die 
node. The intercepted packets may be forwarded to dieir intended destination (e.g., another 
device on die network or die node) if the operator/user is entitled to make die request described 
by die packets (for packets transmitted from die node) or receive die information contained in 
die packets (for packets destined for die node). Whedier die packets are forwarded to dieir 
20 intended destination will be determined by the funaions performed cooperatively by the UCM 
Proxy 214, DICOM decoder 216 and die audientication library 204. 

The packets intercepted by die UCM proxy 214 wiU include die node ID of die node diat was 
die source or die destination of die packets. The UCM proxy will use this node ID for two 
25 purposes; (1) to record an event in die Security Repository 102; and (2) to determine whedier to 
pass die packet onto die intended destination of die packet. 

To generate die event for recording in die SR 102, die UCM Proxy 214 will pass a copy of an 
intercepted packet to die DICOM decoder 216 for processing. The DICOM decoder 216 wiU 
30 decode die received die copy of die intercepted packet and generate XML event describing die 
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proposed activity. The SR 102, thiough a process similar to thai described above, will then 
record this event. 

In determining whether to forward an intercepted packet the UCM proxy 214 will access the 
5 authentication library (using the node ID included in the intercepted packet) to determine 
whetha- the operator of the node has die pemiission to either transmit the request or 
altmatively receive the packet transmined to die node. If die operator does not have die 
requisite permission, the UCM proxy will discard the intercepted packet. Odierwise die packet 
is forwarded to die intended destination. 

10 

As result of the co-operation of die UCM proxy 214, DICOM decoder 216 and audientication 
library three effects result: (1) each activity will be recorded in die SR 102 (regardless of 
whedier pemiission has been granted); (2) only those requests that an operator is permitted to 
make will be transmined to die network (reducing network traffic); and (3) the node will only 
1 S receive packets for which die operator is permitted to receive. 

Persons of ordinary skill the an will tcppteddxt diat invention will provide odier advantages. 
Moreover, various changes, altemations and modifications are possible without varying spirit 
and scope of the invention as defined by the claims herein. For example, aspects of the 
20 invention that are ascribed to die access control node could be performed by a centralised 
server. That is, aspects which are client-side based could be alternatively embodied on the 
server side. Similarly, aspects of the embodiment which are server-side based could be 
alternatively embodied on die client side. Odi^ alternative embodiments of die presem 
invention will be understood by the person of ordinary skill. 

25 
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